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Abstract 

Joint  Vision  2010  describes  an  approach  about  joint  warfare  of  the  future,  and  it  depends  on  and 
highlights  the  contributions  of  air  power.  Accordingly,  the  Air  Force’s  vision  of  Global 
Engagement  flows  from  Joint  Vision  2010.  The  Air  Force’s  Strategic  Plan  outlines  the  core 
competencies  that  are  necessary  for  Global  Engagement.  The  capability  for  attaining  the  desired 
capabilities  and  goals  of  these  visions  depends  on  an  adaptive,  unified,  dynamic  aerospace  C2 
system.  The  unified  C2  system  will  provide  for  the  capability  to  dynamically  assess,  plan, 
execute,  and  project  aerospace  power  in  a  joint  environment.  However,  this  capability  must 
overcome  the  challenges  of  complexity  and  ultimately  affordability,  if  it  is  to  become  a  real 
system.  In  addition,  future  dynamic  C2  systems  must  be  integrated  into  a  system  of  systems  to 
be  effective.  This  paper  discusses  development  approaches  and  technologies  that  offer 
significant  savings  in  overcoming  the  complexities  of  fielding  a  unified  C2  system.  Specifically, 
this  paper  covers  how  existing  aerospace  platforms  can  affordably  insert  the  technology 
necessary  to  operate  with  the  future  dynamic  C2  systems.  Furthermore,  the  paper  discusses  how 
C2  systems  can  be  benefit  from  the  use  of  system  level  design  representations  and  modeling. 

1.0  Introduction 

In  Joint  Vision  2010,  the  Chairman  of  the  Joint  Chiefs  of  Staff  has  provided  a  common  direction 
for  our  military  services  into  the  next  century.  This  vision  calls  for  the  capability  to  dominate  an 
opponent  across  the  range  of  military  operations,  i.e.  Full  Spectrum  Dominance.  The  plan  to 
achieve  this  goal  comprises  four  operational  concepts  to  guide  future  joint  warfare  development  - 
Dominant  Maneuver,  Precision  Engagement,  Full-Dimensional  Protection  and  Focused 
Fogistics.  In  addition,  Full  Spectrum  Dominance  requires  Information  Superiority,  the  capability 
to  collect,  process,  analyze  and  disseminate  information  while  denying  an  adversary's  ability  to 
do  the  same. 

Essential  to  attaining  the  future  capabilities  and  goals  outlined  in  high-level  documents  such  as 
Joint  Vision  2010,  the  Air  Force's  Global  Engagement  vision,  and  the  Air  Force  Strategic  Plan,  is 
enhanced  command  and  control  (C2).  The  systems  that  will  provide  this  enhanced  C2  will 
operate  in  an  operational  environment  that  contains  numerous  interconnected  sensor  and  strike 
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systems.  Since  the  new  C2  systems  will  pass  and  receive  data  and  information  to  these  other 
systems,  the  C2  development  approach  requires  methods  that  reduce  design  complexity  and 
implementation  costs.  Modeling  and  simulation  is  a  key  method  that  can  satisfy  this  need.  In 
addition,  new  technology  is  needed  to  allow  the  existing  systems  to  be  affordably  upgraded  so  as 
to  communicate  with  the  new  C2  systems. 

2.0  System  Level  Design  Representations  and  Modeling 

Future  aerospace  C2  system  will  interface  to  a  system  of  intelligence,  surveillance,  and 
reconnaissance  platforms.  The  result  is  a  system  of  systems.  As  shown  in  the  following  figure, 
this  system  of  systems  is  the  top  level  of  an  architectural  hierarchy. 
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Figure  1 


The  complexity  of  building  a  C2  system  and  modifying  existing  weapon  systems  to  operate  as  a 
unified  system  of  systems  can  be  managed  through  the  use  of  simulation  and  modeling. 
Specifically,  by  applying  the  principles  of  Simulation  Based  Acquisition  (SBA)  and  designing 
with  the  Unified  Modeling  Language  (UML)  and  System  Level  Design  Language  (SLDL).  The 
following  sections  will  discuss  these  areas  in  more  detail. 

2.1  Simulation  Based  Acquisition 

The  vision  for  Simulation  Based  Acquisition  (SBA),  adopted  in  1997  by  the  Acquisition 

Council  of  the  Department  of  Defense  (DoD)  Executive  Council  for  Modeling  and  Simulation 

(EXCIMS),  is  “an  acquisition  process  in  which  DoD  and  Industry  are  enabled  by  robust, 


collaborative  use  of  simulation  technology  that  is  integrated  across  acquisition  phases  and 
programs.”  SBA  promises  to  reduce  the  cost  of  system  development  by  avoiding  the  need  to 
build  expensive  hardware  and  software  first  in  order  to  determine  the  necessary  processing 
resources,  communication  link  bandwidth,  and  resource  management  techniques.  An  architecture 
description  is  necessary  for  SBA.  Accordingly,  models  of  the  system  under  construction  will 
have  to  be  developed.  However,  each  level  in  the  architecture  will  be  modeled  with  a  design 
language  suitable  for  the  particular  domain.  For  example,  the  hardware  components  (Level  6) 
may  be  modeled  using  VHDL  while  the  hardware/software  building  blocks  (Level  5)  may  use 
the  Unified  Modeling  Language.  A  System  Level  Design  Language  (SLDL)  is  suitable  for 
Levels  1  through  Level  4. 

2.2  Unified  Modeling  Language  (UML) 

The  Unified  Modeling  Language  (UML)  is  a  language  for  specifying,  constructing,  visualizing, 
and  documenting  the  artifacts  of  a  software-intensive  system.  UML  is  nonproprietary  and  open 
to  all.  As  a  result,  UML  is  widely  used  by  software  and  system  developers.  However,  UML  is  a 
visual  modeling  language,  not  a  visual  programming  language.  It  does  not  have  all  the  necessary 
visual  and  semantic  support  to  replace  programming  languages.  Fortunately,  UML  does  have  a 
tight  mapping  to  a  family  of  00  languages,  so  the  transition  from  modeling  to  programming  is 
seamless. 

2.3  System  Level  Design  Language  (SLDL) 

SLDL  is  a  language  environment  for  the  specification  and  high-level  design  of  microelectronics- 
based  systems.  SLDL  is  focused  on  system-on-a-chip  design  constraints  and  behavior  at 
architectural  levels  prior  to  HW-SW  partitioning.  However,  nothing  limits  its  use  in  the  higher 
levels  of  the  system.  Work  is  ongoing  to  create  a  standard  SLDL.  Once  complete,  SLDL  will 
enable  engineers  to  describe  embedded  systems  to  any  desired  degree  of  detail  and  that  will 
allow  engineers  to  verify  and/or  validate  those  systems  with  the  appropriate  tools. 

3.0  Upgrade  Technology 

New  upgrade  technology  is  needed  to  achieve  the  interoperability  required  between  the  C2 
system  that  supports  the  Air  Force  vision  of  Global  Engagement  and  the  sensor  and  strike 
platforms.  Existing  systems  will  have  to  be  upgraded  to  become  interoperable  with  future  C2 
systems  if  the  Air  Force  concept  of  dynamic  aerospace  command  is  to  be  realized.  Cost  is  the 
major  barrier  to  these  upgrades.  The  following  sections  describe  key  software  technology  that 
will  enable  existing  systems  to  be  upgraded  to  meet  the  need  for  C2  interoperability. 

3.1  Object  Request  Broker  (ORB)  Technology 

An  ORB  is  the  software  technology  that  manages  communication  and  data  exchange  between 
objects.  The  ORB  is  a  vital  component  in  supporting  a  unified  C2/strike  system.  It  promotes  the 
interoperability  of  distributed  object  systems  by  allowing  objects  from  different  sources  (written 
in  different  languages,  and  executing  on  different  platforms)  to  communicate  with  one  another 
via  the  ORB. 


The  ORB  establishes  the  client-server  relationships  between  objects.  Using  an  ORB,  a  client  can 
transparently  invoke  a  method  on  a  server  object,  which  can  be  on  the  same  machine,  across  a 
network,  or  with  respect  to  a  military  C2/strike  application,  across  a  system  of  systems.  The 
ORB  intercepts  the  call  and  is  responsible  for  finding  an  object  that  can  implement  the  request, 
pass  it  the  parameters,  invoke  its  method,  and  return  the  results.  The  client  does  not  have  to  be 
aware  of  where  the  object  is  located,  its  programming  language,  its  operating  system,  or  any 
other  system  aspects  that  are  not  part  of  an  object's  interface.  In  so  doing,  the  ORB  provides 
interoperability  between  applications  on  different  systems  in  heterogeneous  distributed 
environments  and  seamlessly  interconnects  multiple  object  systems.  The  ORB  is  critical 
enabling  technology  for  a  dynamic  C2  system  to  operate  within  a  system  of  systems. 

3.2  Software  Wrapper  Technology 

With  respect  to  performance  and  affordability,  it  is  difficult  to  avoid  the  influence  existing 
(legacy)  systems  will  have  on  future  Air  Force  C2  systems.  The  C2  systems  needed  to  support 
the  Air  Force  vision  of  Global  Engagement  will  have  to  interface  with  numerous  existing 
weapon  systems.  However,  many  of  these  existing  weapon  systems  were  designed  to  operate 
and  fight  almost  autonomously.  They  lack  the  ability  to  pass  digital  information  within  an 
integrated,  dynamically  adaptive  C2  system.  Accordingly,  without  a  strategy  to  affordably 
upgrade  existing  systems  to  function  within  the  new  C2  environment,  conditions  will  not  change 
significantly.  This  section  describes  an  approach  that  uses  software  wrapper  technology  to 
support  the  affordable  insertion  of  new  functions  within  fielded  weapon  systems.  These  new 
functions  will  enable  the  fielded  weapon  systems  to  connect  to  the  global  information  grid 
envisioned  by  the  Air  Force. 

A  software  wrapper  is  an  adapter  or  a  shell,  which  isolates  a  software  component  from  other 
components  and  its  processing  environment  (its  context).  The  wrapped  component  becomes  a 
software  object.  Its  operational  capability  (functions  and  data)  is  encapsulated,  and  it  can  be 
integrated  through  its  standard  interface  with  other  software  objects  to  form  a  complete  program 
on  a  single  or  distributed  processor  host.  The  wrapper  manages  the  timeliness  of  all  shared  and 
external  data,  and  provides  any  necessary  transformations.  For  upgrades  involving  the  addition 
of  new  C2  interoperability  functions,  the  goal  is  to  develop  this  new  application  using  the  latest 
software  engineering  techniques  (such  as  object  oriented  design)  and  languages  (Ada  and  C++) 
with  minimal  concessions  to  the  internal  structure  of  the  legacy  system. 


Wrappers  are  generally  applied  at  the  application  domain  level.  They  act  as  clients  and  servers 
to  the  encapsulated  component.  The  following  figure  illustrates  a  general  wrapper  structure  for 
an  operational  flight  program  on  a  single  processor.  The  legacy  application  interfaces  with  other 
applications  and  other  layers  only  through  the  wrapper. 

Overall,  the  wrapper  architecture  is  tailored  to  the  specific  legacy  operational  flight  program 
environment. 


Figure  2 
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This  use  of  software  wrapper  technology  and  ORBs,  as  illustrated  in  the  figure  above,  allows  the 
existing  weapon  system  software  to  be  treated  as  an  object  so  as  to  interface  within  the  object 
based  C2  environment  of  the  future. 

Automation  is  critical  in  the  development  of  these  wrappers,  else  there  would  be  little  cost 
advantage  over  the  unaffordable  approach  of  rewriting  all  the  existing  software.  The  figure 
below  illustrates  the  process. 


4.0  Summary 

In  summary,  the  information  based  C2  vision  for  21st  warfare  will  only  occur  it  we  can  overcome 
the  fiscally  constrained  realities  of  the  current  period.  Therefore  technologies  that  promote 
affordable  development  and  implementation  are  required.  This  paper  describes  how  approaches 
for  reducing  the  complexity  and  cost  of  integrating  C2  systems  within  a  system  of  systems.  In 
addition,  dynamic  C2  will  require  that  existing  systems  be  upgraded  to  satisfy  the  need  for 
interoperability.  This  paper  described  technology  that  will  enable  systems  to  be  affordably 
upgraded. 


